Here is a hotpatch if you're interested:

from disnake.ext.commands.view import StringView
from disnake.ext.commands.errors import ArgumentParsingError

_original_get_quoted_word = StringView.get_quoted_word

def get_quoted_word(self:StringView):
    try:
        _original_get_quoted_word(self)
    except ArgumentParsingError:
        raise RuntimeError

StringView.get_quoted_word = get_quoted_word

Err yes, that would probably be better. Trying to make the command work for both actual and test inputs is kinda wack, and properly modifying the test seems like a non-trivial amount of effort.

There seems to be code that handles ArgumentParsingError, so indisriminantely raising RuntimeError in its place seems like it could mess up the parsing of other things

https://github.com/Rapptz/discord.py/blob/01915fbc095a72ffd2231c72b7c0892a377a477c/discord/ext/commands/core.py#L698-L705

There seems to be code that handles ArgumentParsingError, so indisriminantely raising RuntimeError in its place seems like it could mess up the parsing of other things

https://github.com/Rapptz/discord.py/blob/01915fbc095a72ffd2231c72b7c0892a377a477c/discord/ext/commands/core.py#L698-L705

Yep, it would. Oops.

There seems to be code that handles ArgumentParsingError, so indisriminantely raising RuntimeError in its place seems like it could mess up the parsing of other things

Rapptz/discord.py@01915fb/discord/ext/commands/core.py#L698-L705

Yeah the monkey patch seems to no longer infinitely loop but breaks string parsing in most other places as well:

Is there something else we can do for patching?

New much simpler fix in 71fdd6c (#2310) as discovered by @ChrisLovering in https://canary.discord.com/channels/267624335836053506/675756741417369640/1034385695940296704

I think the change in behaviour should be reverted. If we want to change it it can be done in a separate PR after discussing it, but it's out of scope for this PR given the original behaviour was intended

I think that makes sense yeah, usually there's some natural messages after the rules. I reversed the changes in 8f68607 (#2310)

I think the change in behaviour should be reverted. If we want to change it it can be done in a separate PR after discussing it, but it's out of scope for this PR given the original behaviour was intended

Ah right, we should definitely add a comment there explaining that use case then, as it currently just looks wrong to anyone who isn't aware of that.

New much simpler fix in 71fdd6c (#2310) as discovered by @ChrisLovering in https://canary.discord.com/channels/267624335836053506/675756741417369640/1034385695940296704

would you please provide the context for this link that isn't public?

New much simpler fix in 71fdd6c (#2310) as discovered by @ChrisLovering in canary.discord.com/channels/267624335836053506/675756741417369640/1034385695940296704

would you please provide the context for this link that isn't public?

It's just this diff that chris posted:

🕙 09:39:18 ❯ git diff
diff --git a/bot/exts/info/information.py b/bot/exts/info/information.py
index 2592e093..253c24fc 100644
--- a/bot/exts/info/information.py
+++ b/bot/exts/info/information.py
@@ -524,7 +524,7 @@ class Information(Cog):
         await self.send_raw_content(ctx, message, json=True)
 
     @command(aliases=("rule",))
-    async def rules(self, ctx: Context, *args: Optional[str]) -> Optional[Set[int]]:
+    async def rules(self, ctx: Context, *, args: Optional[str]) -> Optional[Set[int]]:
         """
         Provides a link to all rules or, if specified, displays specific rule(s).
 
@@ -541,7 +541,7 @@ class Information(Cog):
             for rule_keyword in rule_keywords:
                 keyword_to_rule_number[rule_keyword] = rule_number
 
-        for word in args:
+        for word in args.split():
             try:
                 rule_numbers.append(int(word))
             except ValueError:

@ionite34 @ChrisLovering here's the - original issue where you'll find more details and context in the discussion / PR about the actual behavior